Columbia Kermit/kermit.zip/newsgroups/CURRENT/[e-mail]_Mon Apr 14 13:25:30 2008.msg

Internet Message Format | 2020-01-01 | 7KB

Path: reader2.panix.com!panix!newsfeed.stanford.edu!postnews.google.com!news1.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news1.optus.net.au!optus!newsfeeder.syd.optusnet.com.au!news.optusnet.com.au!not-for-mail
Date: Sun, 06 Apr 2008 08:03:35 +1000
From: PC Pete <[e-mail]>
Reply-To: [e-mail]
Organization: Audiography
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Help with CPVGEN sources : Problem found
References: <[e-mail]> <47f49f53$0$20462$[e-mail]> <47f4abe0$0$13262$[e-mail]> <47f5ec7a$0$8090$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 141
Message-ID: <47f7f743$0$8036$[e-mail]>
NNTP-Posting-Host: 122.107.177.239
X-Trace: 1207433028  8036 122.107.177.239
X-Original-Bytes: 7105
Xref: panix comp.protocols.kermit.misc:15750

Frank da Cruz wrote:
> On 2008-04-04, PC Pete <[e-mail]> wrote:
> : ...
> : Thanks to all for your wonderful ideas, it's nice to have someone more
> : experienced offer help, especially when you're as rusty as I am!
> :
> I'm more rusty.  The last time I actually worked with this code was over
> 20 years ago and I'm sure it goes without saying that I don't have any
> machines here where I could do it again.  I don't understand why the "native
> TurboDOS" version doesn't work, but then I've never even seen TurboDOS.
> Unfortunately I don't see any other grizzed CP/M Kermit veterans popping
> up with advice.
>
It's not that surprising, Frank, I'm more surprised that this newsgroup
is still alive and kicking at all! Mind you, it's a bit like going into
a wonderful old hotel that's been bypassed by new highways - the
furniture and fittings are still there, one or two "grizzled" staff
greet the infrequent guests, but we watch the old billboards fade while
dust quietly gathers in the corners...

> I also noticed this directory, which I had forgotten about:
>
>   ftp://kermit.columbia.edu/kermit/old/misc/cpmtools
>
> It contains source for LASM and MLOAD.
>
That's a good find - I didn't dig too deeply, I was too fixated on
finding other mirrors with different source sets. I'll try that out (I
think LASM/MLOAD might deal with the merging problems better than DDT.

> But maybe there's a simpler approach.  The object of the game is to get
> your files OFF TurboDOS and into the PC, right?  Getting things INTO TurboDOS
> is evidently problematic.
>
Yep, this is (for now) a one-way only problem. I have to get the oil OFF
the sinking tanker.

> And both TurboDOS and the PC support RTS/CTS flow control, right?  So for any
> text file on TurboDOS, shouldn't you be able to TYPE it to the serial port?
> And have the PC terminal emulator capture it to a file?  It's not elegant, but
> you only have to do it "just this once".  If it's really RTS/CTS flow control,
> you should be able to do this at any speed that TurboDOS supports and you have
> a true null modem cable:
>
>   http://www.columbia.edu/kermit/cable.html
>
You read my mind. The problem for me is that on a 64-bit OS, none of the
terminal emulators work properly (the only one that offers some help in
the form of waiting for simple characters and so on is a real 16-bit
Windows 95 emulator with no buffer capture).

> If you have Kermit 95 on the Windows box, the commands would be LOG SESSION
> (to start logging) and CLOSE SESSION (to stop).
>
At the moment, the only kermit I have working is the one that's rolled
into the terminal emulator, and that's not programmable - it just sends
or receives kermit "packets" - if it doesn't receive kermit protocol
information, it treats the data as bad.

> If you have to send binary files, you'd have to ASCIIize them first, of
> course.
>
> With some programming on each end, you could even automate the process.
> The TurboDOS program would loop through all the files, sending first some
> kind of distinctive text header containing the filename, like:
>
>   >>> BEGIN filename-goes-here <<<
>
> then the file contents, then (not strictly necessary) a footer:
>
>   >>> END <<<
>
> A Kermit script could be written that waits for a header:
>
>   INPUT 9999 <<<
>
> parses it (I'll supply details if you're interested), and then opens
> a session log using the filename from the header:
>
>   LOG SESSION filename-goes-here
>
> and waits for the footer:
>
>   INPUT 9999 >>> END <<<
>   IF FAILURE (fill in what to do if this fails)
>   CLOSE SESSION
>
> All this in a loop.  If you wanted to get fancy, you could also have an
> end-of-session footer to terminate the loop.  Or other embellishments like
> transmitting the file date.
>
> With a short cable and the high speed of the Windows box and hardware flow
> control driven by the receiver, you should have pretty much error-free
> transfers.
>
I've already written ascii-fiers and de-ascii-fiers that work, I was
just hoping to avoid having to loop through the 7,000-odd files on 40
user areas on 5 drive volumes, many of which are now corrupt or
unreadable. But I've already spent more time trying to find out why
Kermit doesn't compile than I would have spent doing a
findfirst/findnext looped transfer of files in a simple protocol as
you've suggested.

> Sorry to not respond to all your posts promptly but as I might have mentioned,
> Columbia U no longer supports netnews so I have to find the time to go
> elsewhere to read news.
>
> - Frank

Don't apologise, it's me who should apologise for spewing updates and
data here without fully understanding the intricacies of the kermit
compile requirements, and 15+ years since I last M80'd in anger.

I appreciate every word you've been able to suggest. I'll spend a couple
more hours to see if I can get any debugging done (after compiling and
linking with masm/mload) and using my newly-captured CPSKER.PRN, and if
not, I'll bite the bullet and 'do the washing by hand'.

I've also finally got my WinXP-32 virtual machine running, that will
give me true access to the comm ports on the PC in a 32-bit environment,
which will open up some other transfer options with different serial
tools (I hope)! I've also dusted off and fired up my PC-XT with a whole
bunch of serial comms software (Telix Procomm, MS-DOS kermit, etc) on
it. Unfortunately the serial hardware access in the MS-DOS virtual
machines isn't as robust as in the XP virtual machine. So there are a
few bridges yet to burn...

Thanks again for all the ideas and suggestions, I really appreciate the
help. I really really really want to be able to give something back. But
don't hold your breath...

Kind regards
PC Pete



--
--
"I want to die peacefully in my sleep, like my grandpa, not screaming
and crying, like the passengers in his car." -Unremembered source from
the (19)90's.